stack: Only map children when necessary

gtk_widget_set_parent() will map the widget if the parent is mapped
and the widget is both visible and child-visible. As we currently
only set the child visibility after adding the child, we immediately
map all children that are added to a mapped stack, even when they
are not actually shown. Avoid this by setting the child visibility
before adding the child, so widgets are only mapped when shown.

https://bugzilla.gnome.org/show_bug.cgi?id=766737

Adwaita: add vertical margins to switches on a headerbar

See https://bugzilla.gnome.org/show_bug.cgi?id=766642

Adwaita: shave 1px from the switch

make the switch height and width 1px smaller.

Improve external drives detection

Use g_drive_is_removable for external drives detection. Current heuristic
fails in some cases (e.g. when removable drive is attached before login),
see Bug 765457.

Bump GLib version accordingly.

https://bugzilla.gnome.org/show_bug.cgi?id=765924

gtktextview: fix < public > comment

This was causing problems with the gtk# scanner

treeview: Fix a rubberbanding-related crash

When starting a rubberband selection from an empty area, we could run
into crashes if the selection moves over the rows and then back out
to unpopulated area. Handle this case without crashing.

https://bugzilla.gnome.org/show_bug.cgi?id=766336

scale css node test: Adapt to changes

The style classes are reflected in the output here.

color scale: Sync style classes with GtkScale

We should use the same style classes here, to avoid theme
confusion.

color scale: Really sync style classes with GtkScale

sync the alpha scale styleclass too.

Adwaita: fix scale theming

rely on toplevel styleclass for scale with marks.

See https://bugzilla.gnome.org/show_bug.cgi?id=766440

gtkselectionprivate: minor style fix

This seems to make some issue with the gtk# scanner.

scale: Use more succinct names for style classes

Use .marks-before/after to indicate the presence of marks.
As Lapo points out, compatibility with the previous names
is not really that important, since everything else changed
around it.

https://bugzilla.gnome.org/show_bug.cgi?id=766440

icon theme: Add a warning

Warn about the situation when we've found a resource or file path,
but gdk-pixbuf fails to give us a pixbuf. This generally means that
either pixbuf loaders are not found or the shared-mime database
is missing.

wayland: Survive lack of settings

This can be made to happen eg by setting XDG_DATA_DIRS and
XDG_DATA_HOME to /. Not a useful value, but not a good reason
to crash either.

wayland: Make gdk_wayland_window_get_wl_output() private

There is no need to make it a public API, move it to the private header
instead.

https://bugzilla.gnome.org/show_bug.cgi?id=766566

Updated Slovak translation

wayland: Add get_monitor_at_window to Wayland backend

Given that Wayland has no global coordinate, the only way for gdk to
retrieve the monitor a window last entered is to retrieve it from the
GdkWaylandWindow itself.

Implement the backend specific get_monitor_at_window() to return the
monitor that was last entered by the window.

https://bugzilla.gnome.org/show_bug.cgi?id=766566

wayland: Add API to retrieve the Wayland output

In Wayland, surfaces get an enter/leave notification each time they
enter or leave an output.

Add an API to GdkWaylandWindow to retrieve the output the window has
last entered.

https://bugzilla.gnome.org/show_bug.cgi?id=766566

display: Add vfunc for get_monitor_at_window

Some backends (namely Wayland) do not support global coordinates so
using the window position to determine the monitor will always fail on
such backends.

In such cases, the backend itself might be better suited to identify
the monitor a given window resides on.

Add a vfunc get_monitor_at_window() to the display class so that we can
use the backend to retrieve the monitor, if the backend implements it.

https://bugzilla.gnome.org/show_bug.cgi?id=766566

scale: Bring back marks-related style classes

It turns out that it is too hard (and in some cases, impossible)
to get this information from node positioning, so bring back the
.scale-has-marks-above/below style classes on the main node.

This should allow us to fix the 'pointy sliders'.

https://bugzilla.gnome.org/show_bug.cgi?id=766440

Revert "scrolledwindow: Better size requisition for GTK_SCROLL_NATURAL children"

This reverts commit 096bea3f0ea8e80fe4c9a2a1a860f32c8a94cc33.

This was accidentally pushed.

x11/dnd: Ignore grab broken events from other devices than our DnD device.

The GdkDragContext should only listen to GDK_GRAB_BROKEN events sent to
its own pointer device. It turns out that the passive key grabs mistake
GDK into sending a GdkEventGrabBroken on the master keyboard, which the
DnD machinery mistakes as a signal to cancel the operation.

https://bugzilla.gnome.org/show_bug.cgi?id=766442

wayland: Avoid spurious crossing events from master touch device

Only generate crossing events on wl_touch.down for the virtual master
device used for touch events, and only whenever this virtual device
actually moves across surfaces. This behavior resembles better what is
expected in X11, where the pointer is warped to the touch position
on XITouchBegin.

This avoids the double emission of leave events when the pointer
emulating touch is lifted, that crossing event will be instead
generated when/if the focus surface changes.

https://bugzilla.gnome.org/show_bug.cgi?id=766314

gdk/wayland: use the multi-thread safe wayland API

This is required for proper integration with any other library/application that
may perform wayland API calls and poll() the wayland fd from multiple threads.
Using wl_display_dispatch{_queue}() is thread-safe if not mixed with custom
poll() usage, which GSource/GMainContext does.

Essentially, the problem is that multiple threads polling and reading
the same fd is extremely racy.  Use the wayland provided API for allowing
concurrent access to the wayland display fd.

See the wayland man pages for wl_display_prepare_read(),
wl_display_cancel_read() and wl_display_read_events() for more details.

https://bugzilla.gnome.org/show_bug.cgi?id=763852

scrolledwindow: Better size requisition for GTK_SCROLL_NATURAL children

GtkScrolledWindow leans towards using the minimum size of its child
widget, unless the scrollbar policy is GTK_POLICY_NEVER. This is
probably fine for most GtkScrollable implementations out there.
Especially when using GTK_SCROLL_MINIMUM, which is the default for all
implementations inside gtk+.

However, this is not good for GTK_SCROLL_NATURAL children. eg.,
VteTerminal's minimum size is 1x1 and natural size is the number of
visible rows and columns requested by the user. We really want to use
the natural size unless the user has resized the window to change that.

https://bugzilla.gnome.org/show_bug.cgi?id=766569

Update cursor docs

Include new images for context-menu and for no-drop.

gtk-demo: Update no-drop cursor image

Adwaita is using a different cursor for this now.

gtk3-demo: Add context-menu cursor

The Adwaita cursor theme covers this one now.

scrolledwindow: Remove redundant use of MAX

This code tries to add the minimum content size, if one is set, to the
GtkScrolledWindow's size requisition. This is obvious from the check
for non-negative values of min-content-height and min-content-width.
Using MAX needlessly makes the code harder to read by implying that
there is more to it when there actually isn't.

Fall out from 0d9ebb501df60cf1803858efcd1c79542588abd8

https://bugzilla.gnome.org/show_bug.cgi?id=766569

Updated Kazakh translation
(cherry picked from commit d1585a7a60d760a0c98934f970c4403023a399c3)

scrolledwindow: Fix typo in get_preferred_height calculation

When we are beginning to calculate the height, if the vscrollbar_policy
is not GTK_POLICY_NEVER, and there is no min-content-height, then we
need some small non-zero value to get started. The idea is to always
ask for at least enough to fit the horizontal scrollbar.

Simply put, this should be the mirror image of the corresponding width
calculation code.

Those who got used to the buggy behaviour might notice that their
GtkScrolledWindows are not as tall as they used to be.

Fall out from 55196a705f00564a44647bfc97981db0a783369a

https://bugzilla.gnome.org/show_bug.cgi?id=766530

stack: always update window position at transition start

Sometimes on wayland we're seeing a frame draw before the first tick
callback, where the window position has not yet been updated.

With this change, the window is properly positioned as soon as
gtk_stack_start_transition returns.

https://bugzilla.gnome.org/show_bug.cgi?id=766405

Use upstream gettext

https://bugzilla.gnome.org/show_bug.cgi?id=373745

Updated Spanish translation

Updated Portuguese translation

Updated Portuguese translation

scale: Avoid a crash

gtk_scale_get_layout was not careful enough, leading to a crash
when opening the inspector on a scale.

widget: fix GtkLabelAccessible NULL links.

Fix testsuite/a11y/about.ui GtkAboutDialog :
"CRITICAL **: atk_hyperlink_get_start_index: assertion 'ATK_IS_HYPERLINK (link)' failed"
That is set widget->priv->accessible as soon as accessible object is generated.

When accessible object is created accessible->priv->widget is set,
if widget->priv->accessible is not , then _gtk_label_accessible_update_links
exits early, thus without creating the links on the accessible side.
(This as it checks for the widget to have the accessible set before proceeding).

https://bugzilla.gnome.org/show_bug.cgi?id=766458

widget: No longer postpone style-updated on unrealized widgets

GTK used to not emit GtkWidget::style-updated on widgets that weren't
realized. This sped up construction of complex widgetry in the early
days of GTK3 where we instantly invalidated on every change.
We don't do that anymore, so in theory (and in my limited testing with
widget-factory) this shouldn't be a prolem anymore.

What is a problem though is that postponing style-updated leads to 2
problems:
(1) Unrealized widgets will not emit style-updated which may cause them
    to not properly update their state and return wrong values from
    get_preferred_width/height() etc
(2) Emitting style-updated during realize can happen too late.
    When a widget is not made child-visible by its parent (common
    examples: notebook, paned) it will also not be realized when the
    parent is initially shown. However, when they get realized later
    (after a resize of the parent), they will emit style-updated (and
    potentially queue a resize) during size-allocate.

https://bugzilla.gnome.org/show_bug.cgi?id=765700

scrolledwindow: destroy children in destroy()

If we don't do that, testsuite/gtk/templates starts failing.

gdkwindow: Use GList less

query-settings: Indicate deprecated settings

stack: Don't underallocate the last_child

stack: Remove some code duplication

Remove useless casts from gdk_event_triggers_context_menu calls

query-settings: Don't compare int to uint

listbox: Don't compare int to uint

colorbutton: Stop using state-changed

toolbar: Limit item position to number of contained elements

Greater values don't make much sense.

https://bugzilla.gnome.org/show_bug.cgi?id=682080

wayland: Avoid unitialized memory reads

I didn't pay attention when I replaced g_new0 with g_newa. Oops.

Adwaita: brighter pushed button background

providing more contrast with the text color.

Adwaita: bold size label on font button

looks more consistent with other special buttons with icons.

Adwaita: hide separator on button.font and button.file

we used to do that, got missed at some point during 3.20 cycle.

Docs: Clarify life cycle issue

gtk_gesture_get_last_event() wasn't very clear about how long
it is safe to use the returned pointer.

DND: Avoid a use-after-free

Cancelling the gesture causes the last_event pointer to become
invalid. Make a copy of the event so we can keep using it
regardless of the gesture state.

places sidebar: Avoid markup confusion in tooltips

At one point, the sidebar was using gtk_treeview_set_tooltip_column,
which expects tooltips to be markup. With the listbox-based sidebar,
we don't do that anymore. So don't escape the tooltip text.

https://bugzilla.gnome.org/show_bug.cgi?id=766175

x11: Trap possible X error

XIGetClientPointer can generate X errors (e.g. when the X server
does not support XI2. Trap them and carry on.

https://bugzilla.gnome.org/show_bug.cgi?id=766233

Fix scale length

The vertical scales should really be of the same length, so
add an empty value to be drawn by the other scale.

Forgotten rename

Scale: Set the correct value alignment

We're measuring both the width of the minimal and the maximal value for
the value gadget, but only give the value the minimal width for its
current value, resultnig in an always left-aligned value.

Fix this by assigning the width of the value gadget to the value layout
and letting pango align the text inside the layout.

https://bugzilla.gnome.org/show_bug.cgi?id=766120

widget-factory: Let one of the scales draw a value

https://bugzilla.gnome.org/show_bug.cgi?id=766120

Document new api

Make gdk_event_get_pointer_emulated public

There is not strong reason to keep the getter private.
At the same time, strip _-prefixes from a few other GdkEvent
APIs. Update all callers.

gtkmenu: ignore left/right scroll events

Menus are placed vertically by definition, it does not make much sense
to support horizontal axis for scrolling.

Use GDK_EVENT_STOP/GDK_EVENT_PROPAGATE instead of TRUE/FALSE and add a
default case to return GDK_EVENT_PROPAGATE for unhandled events.

https://bugzilla.gnome.org/show_bug.cgi?id=765939

gtkmenu: ignore emulated scroll events

On X11, we get both smooth and emulated scroll events, whereas other
backends such as wayland will give smooth events only with touchpad
scrolling.

Discard emulated scroll events so that we get consistent behaviours
between backends.

Allow for both horizontal and vertical smooth events for scrolling so
that horizontal scrolling still works without emulated scroll events as
well, again for consistency between gdk backends.

https://bugzilla.gnome.org/show_bug.cgi?id=765939

gdkevent: make _gdk_event_get_pointer_emulated() private

And not just internal to gdk, so we can use it in gtk as well, to
differentiate emulated scroll events from others.

https://bugzilla.gnome.org/show_bug.cgi?id=765939

scale: Remove double nullable annotation

Being both (allow-none) and (nullable) at the same time is a bit much.
Was from 591e7f5ef8538982e227b2c2cefc536a33cafa6c.

widget: Add Since annotation to gtk_widget_queue_allocate

GTK: Fix build for pre-C99 compilers

Some compilers we support, such as pre-2013 Visual Studio, does not support
for INIFINITY, log2() and exp2(), so check for exp2() and log2() during
configure, and use fallbacks for them and INIFINTY if they are not found.

https://bugzilla.gnome.org/show_bug.cgi?id=766207

Visual Studio builds: Refine "installation" process

Split out the part where we generate/update the caches for the GSchemas
and the icons, so that it is easier to ensure that things continue to
function correctly when we have GlibEtcInstallRoot != CopyDir.

scrolledwindow: Remove child before destroying self

Children tend to call back into the scrolled window while being removed
and that doesn't work too well if the scrolled window is destroyed
already as Christian Hergert found out.

cssimage: Make it possible to shrink builtin check/optionmarks

... below 7px of size.

Updated Occitan translation

docs: Update examples of matching key bindings

The selector for matching GtkEntry has changed to `entry` after 3.20.

https://bugzilla.gnome.org/show_bug.cgi?id=766166

gdk/Makefile.am: Dist gdkmonitorprivate.h

This file needs to be distributed with the tarball as well...

Visual Studio builds: Clean up projects a bit

Consolidate the .lib's that we need to link to for GDK and GTK+ into the
property sheets, and also link to setupapi.lib as that is needed by
the port to the new GdkMonitor API.

gdk/win32/gdkmonitor-win32.c: Fix build on non-GCC

WINBOOL is MinGW-specific, so change it to BOOL, which is universally
available.

Also, Visua Studio is more picky on where __stdcall (WINAPI) is placed, so
fix that to be in-sync with what is done in the other sources.

placesview: update guiding list of protocols

The previous list of protocols in the guidance popover
was suboptimal and needed adjustments.

This commit updates this list to match the latest mockups [1].

[1] https://raw.githubusercontent.com/gnome-design-team/gnome-mockups/4847c79ea1aaf75046b3ec5bb1b167ac604d86ed/nautilus/nautilus-next/connect-to-server-wire.png

https://bugzilla.gnome.org/show_bug.cgi?id=756570

dialogs: remove 2px border width again

Updated Lithuanian translation

Updated Brazilian Portuguese translation
(cherry picked from commit 207b793316a90faff00d5ea6fbe483d5a184d066)

tooltip: Include gtkwidgetprivate.h

That's where gtk_widget_query_tooltip is defined.

gdk: Fix parameter name mismatch

infobar: Fix typo

Style class names are prefixed with a '.'

gtk-demo: Fix revealer demo

This only used by luck before. We are changing a property from the
::notify handler for that property. Now that GtkRevealer is notifying
the property when it stops animations on unmap, we end up in a life
lock situation where we never make it out of the notify queue.

Fix this by not restarting the animation if the widget is unmapped.

widget: add missing detail to ::query-tooltip emission

This was an oversight in commit dfb368e29bb58b4313b578f0ce75cfc8ead9a1.

tooltip: Add a missing *

This was an oversight in the previous commit.

gtk3-demo: Add a close button to the markup window

gtk-demo: Don't duplicate text in markup example

I forgot to clear the buffer before inserting the new markup. Oops.

revealer: emit notify::child-revealed when animation stops

Depending of float rounding during target calculation, the size of the
GtkRevealer can be set to zero will the animation is not finished.
If the GtkRevealer is in a GtkPaned, it will be hidden and so the animation
will be stopped before it is finished.

In this case, force the emission of the child-revealed signal to let
client code know the animation is finished.

https://bugzilla.gnome.org/show_bug.cgi?id=765973

Simplify our templates

This is applying the new property name simplification.

Clean up builder parser data after parsing

No need to have these linger around in qdata.

builder tool: Canonicalize property names

When simplifying, convert property names to canonical form,
so we don't waste time while looking them up later.

Updated Occitan translation

Adwaita: darken treeview exapanders

Adwaita: cosmetic change

Adwaita: relocate a selector

relocate treview acceleditor > label in the treeview section and
add a comment for a testcase.

Avoid emitting ::style-set by name

GtkStyle is deprecated, but we still emit ::style-set quite
a bit, so lets at least not be slow while doing it.

Don't emit ::query-tooltip by name

This signal is emitted quite a bit, and we can easily avoid it.

Stop storing has-tooltip in qdata

This is queried quite a bit, and we have room for an extra
bit in GtkWidgetPrivate.